home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
BBS Toolkit
/
BBS Toolkit.iso
/
gt_power
/
qcvt105.zip
/
ADDENDUM.NET
next >
Wrap
Text File
|
1989-10-26
|
57KB
|
1,274 lines
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PLEASE note these new phone numbers. THANK YOU!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Voice: (602) 285-9914 Modem: (602) 285-1146 Netmail: 009/000
(713) 772-2090 001/003
- more -
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ADDENDUM TO NETMAIL DOCUMENTATION
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Copyright 1989 P&M Software Co.
October 26, 1989
All rights reserved.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Netmail Version 300 10-26-89
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. MDRIV now supports baud rates in excess of 19,200. So all you
guys 'n gals can try 38,400 baud.
This program must now be installed to use. The installation procedure
is quite simple, the first time the program is run, it will prompt you
for the required information: name, S/N and GT key. The program should
not be renamed until successful installation has been done. Also, you
should have the program in the GTPATH directory and it should be made
the default directory when the installation is done.
Also, when a connection is made between MDRIV's 047 and above, the
GTNET.LOG will show you that S/N and first 9 characters of the
registered owners name. This will help us track the source of
unauthorized usage.
2. The netmail programs now support file inclusion. That is you can break
your routing file down and build them back.
For example, my ROUTING.BBS looks like this:
;
; MAIN NETMAIL ROUTING FILE FOR 001/033
;
$ PURSUIT.RTE
;
$ OUTBOUND.RTE
;
$ WINDOWS.RTE
;
$ ROUTE.RTE
$ ECHO.033
END
;
$ DISTRIB.RTE
;
ECHOMAIL HOURS 0100-2459
Each line that begins with a '$' names another file to be included
into the current ROUTING.BBS. This makes it very easy to track each
functional section of the routing file. File inclusion is completely
optional.
3. (Q)uick Bags!
(Q)uick Bags are replacements for the old E bags. You know the bags
that are named like this: E0954001.E00. Now we will have a replacement
for the E bags, named like the E bags, but with the first character
of the filename equal to Q, like this: Q0954001.E00.
(Q)uick bags are 20-50% smaller than regular E bags created with PKARC,
and maybe even smaller than ZIPped E bags, since these archivers do not
handle small files like messages well. To create a (Q)uick bag we use
our own squeeze program, called NMSQ (which must be placed into your
GTPATH directory). Also, the WORDLIST file must be present. This is
a dictionary of words used in a pre-compression process.
There are two new command line arguments, /Q and /QO, for MBAG.
These arguments enable the creation of (Q)uick bags. MDIST will
continue to be able to unpack both types of bags.
When you specify the /Q option on the command line of MBAG, (Q)uick
bags will be generated for all conferences that are sponsored on your
system, in addition to the regular E bags. You may examine the
results to see the efficiency (or lack thereof) of the new procedure.
The /QO option will cause MBAG to generate (Q)uick bags ONLY. If you
require E bags later, the QCVT program can be used to create E bags
from your (Q)uick bags. The QCVT program is described below.
Selective generation of (Q)uick bags is possible by adding a Q to the
line in the MESSAGE DISTRIBUTION section for the indicated conferences.
Like this:
MESSAGE DISTRIBUTION
E01/009,10 -> D:\BETA_ECO , ;GT_Beta_Echo
E01/011,10,Q -> D:\TEST_ECO , ;Q_Test_Echo
END
In this example, E01/009 will have only E bags generated and E01/011
will have both (Q)uick and E bags generated. Of course, this assumes
that no /Q is given on the MBAG command line. This syntax is only
useful for conferences that you sponsor.
Selective inclusion of (Q)uick bags in G bags may be accomplished by
a similar mechanism in the BAG CONSOLIDATION section. Like this:
BAG CONSOLIDATION
001/032,Z
E00/001,955
E01/009,955
E01/010,955
003/000
E01/009,955
E01/010,955
009/000,ZQ
E00/001,955
E00/005,955
END
In the above example, nodes 001/032 and 003/000 will get normal E bags
put into their G bags, but node 009/000 will receive (Q)uick bags if
they are available. If (Q)uick bags are not available, then 009/000
will receive regular E bags.
Notice, as well, that 001/032 and 009/000 receive ZIPped G bags.
4. The QCVT program is being made freely available to everyone. It will
perform three different tasks:
A. Take E bags and make (Q)uick bags from them. Option /Q.
B. Take (Q)uick bags and make E bags from them. Option /E.
C. Take (Q)uick bags and make M files (in \MAILWORK). No option.
Here are some command line examples:
QCVT [filespec] [option]
If not specified, the filspec will default to \MAILOUT\*.*
If not specified, the option will default to C above, which
breaks down (Q)uick bags into their component M files.
QCVT /E
Means to search \MAILOUT for all (Q)uick bags and generate E
bags, if they do not already exist.
QCVT /Q
Means to search \MAILOUT for all E bags and generate (Q)uick
bags, if they do not already exist.
QCVT q0955001.e01
Take this (Q)uick bag and break it down into M message files
in the \MAILWORK directory.
5. A new file, WORDLIST must be placed into the GTPATH directory. This
file contains a dictionary of words used to pre-compress the new
(Q)uick bag format. DO NOT change this file in ANY way. To change
this file will prevent the Q bags from being properly decoded on your
system.
6. MDRIV now supports the use of **UNLISTED** in the NODELIST. This
indicator may be placed on ANY node, however it is primarily intended
for use with Independent Nodes and Independent Points (900 series node
numbers).
7. MDIST has been modified to more gracefully handle damaged ARC or ZIP
files. That is, if any damaged ARC or ZIP file is found, the following
will occur:
1. The GBAG log will contain an ERROR message reporting the fact.
So be sure that GBAG logging is enabled.
2. The damaged bag, either B, E or G, will be moved to the
\MAILIN\PROBLEMS directory for your manual inspection and
disposal.
8. MBAG and Independent Nodes
MBAG will now recognize Independent Nodes and a sub-variation of that
which we will call Independent Points. An Independent Point would have
a different entry in the nodelist. An extra column would be added
after the Sysop's name with the node number of a server for the point.
Like this:
001/999 713-999-9999 24 Houston FIDO<->GT NGC Gateway Mel Douglass (001/010)
Please notice that a column has been added, at the end of the line,
which contains "(001/010)". 001/010 would be the Point Server for
001/999.
What does this mean?
First, MBAG will not consolidate netmail for any Independent Node
(point or not) in the normal sense. For example, if you have the
following routing statement in your routing file:
ACCEPT 001/000-999 -> 022/000
MBAG will automatically convert this to:
ACCEPT 001/000-899 -> 022/000
In other words, Independent Nodes will be restricted from the normal
flow of netmail through the hub systems. This may be overridden, if
need be, in much the same way as outlined above for MDRIVER, i.e.
ACCEPT 001/000-899 -> 022/000
ACCEPT 001/900-999 -> 022/000
But, be aware, most hub systems will not welcome mail for Independent
Nodes.
If, however, the Independent Node happens to be a "point", then MBAG
will automatically consolidate mail for the Independent Node in a G
bag addressed to the Point Server. For example, in the case of
001/999 above any B bag for 001/999 would be placed, automatically,
into a G bag for 001/010, the Point Server for that Independent Node.
Not all Independent Nodes will have a Point Server, in which case they
will be totally responsible for handling their own netmail. They will
have to "drop the nickel", in most cases, to call and collect their
mail, otherwise it will simply go stale.
9. The operator may use a /P option on the MDRIV command line to allow
calls to be placed to Independent Nodes. The /P option would say,
"It's okay to call 900 series nodes".
/P ... Allow calls to be made to 900 series nodes.
Normally, no call would be made to 900 series systems.
Also, MDRIV will not forward netmail for Independent Nodes.
For example:
ACCEPT 004/000-999 -> 015/000
Would be converted automatically to:
ACCEPT 004/000-899 -> 015/000
You may override this conversion, if you wish by placing the following
lines in your routing:
ACCEPT 004/000-899 -> 015/000
ACCEPT 004/900-999 -> 015/000
Please note that it is expected that most hub systems will not welcome
such mail movement for Independent Nodes, so you should think carefully
before overriding the default action.
10. Support for BIMODEM for netmail transfers.
It is possible to specify a max baud rate for BiModem. By using these
options on the MDRIV command line:
/I Use BiModem. Not on PC Pursuit. No max baud rate.
/I2400 Use BiModem. Not on PC Pursuit. At or below 2400 baud.
/IP Use BiModem. Enable PC Pursuit. No max baud rate.
/IP4800 Use BiModem. Enable PC Pursuit. At or below 4800 baud.
The max baud rate may be any rate up to 9600. Over course, it is
unlimited if not specified.
I have added code, as directed by Erik Labs, to try and overcome
problems reported with PC Pursuit. Using Zmodem we "set 5:1" on
PC Pursuit, the new code will switch to "5:0" prior to invoking
BIMODEM.
I have reported problems with excessive error retries to Erik Labs.
They have responded with v1.14 which will allow the sysop to specify
the maximum number of error retries.
PS: You will need to install the new BITX.BAT and GTBIMOD.EXE files to
use the BiModem transfers during netmail.
WARNING: You should be sure that BiModem is properly working and
logging during regular host mode operations, before turning
it on for use with netmail.
And lastly, I encourage all of you who are going to use BiModem to
register with John Erickson. He is not asking much, I believe his
"Sysop Deal" is $10 and regular registration is $20 or $25 (not sure
which). But this new protocol is a real winner, it is worthy of
your support!
11. MDIST now supports up to 200 entries in MESSAGE DISTRIBUTION
section of the routing file.
12. New GTBIMOD.EXE.
A new version of GTBIMOD.EXE is being introduced to correct some bugs
in the handling of time limits during netmail operation.
13. MBAG has been fixed so that it will not G bag items for a net/node that
has a DX or FR outstanding. The reason for this is that if the DX or
FR is bagged, then it will not take effect, especially if you are
routing normally thru a 3rd party.
14. The /VG option has been added to MBAG and MDIST. This option will
produce a verbose listing of the GCONSOL file onscreen (which was the
previous normal action). Without the /VG option, the GCONSOL file
will not be listed.
15. The /Tm:n option has been added to MDRIV. This option allows the user
to specify the allowed maximum times in seconds to be connected to
PC Pursuit and to still be allowed to redial on a BUSY. In other
words, when the program is about to redial after a BUSY, it checks the
current connect time against this limit, if the limit has been exceeded,
then it will cease redialing and disconnect from PC Pursuit. I will
refer to 'm' as the T1 time, which is measured from the very first
CONNECT to the PCP modem in your local area to the time you are
connected to the modem in the remote city. T2 is the time you are
connected to the remote city. PCP has said that there will be a 60
seconds setup time allowance, I have taken that to mean that T1 must be
kept under 60 seconds. The T1 time limit will default to 45 seconds,
which means that MDRIV will not attempt to redial a remote city if
T1 exceeds 45 seconds. PCP has said that there will be 90 seconds
of no charge time once you are connected to the remote city, so T2 must
be less than 90 seconds. T2 will default to 50 seconds, which means
that MDRIV will not attempt to redial a BBS or NM system if T2 exceeds
50 seconds. The time limits are only checked prior to performing a
redial operation, so if the result of the redial are slow coming back,
the 60 second or 90 second limit could be exceeded.
An example of setting these limits:
/T45:50
This would be the same as the defaults.
Also the logging has changed again to reflect these new limits:
08-05 20:22 PCP CONNECT HOUSTON 602 7B
08-05 20:22 PCP DISCONNECT T1=00:00:12 T2=00:01:03 TOT=00:01:16
This new format shows the time break down for T1, T2 and TOTAL.
The T2 time probably matches the billed time as closely as I can
tell. But if T1 exceeds 60 seconds, there may be extra billings
made, I am not clear on how the 60 second setup allowance works
with T1.
16. The new MBAG program corrects a problem which caused premature pruning
of bags, before they could be included in G bags for retransmission.
This showed up on systems which had a very small value on the MBAG
command line for number of days to keep on-hand.
Regards,
Paul Meiners
October 26, 1989
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Netmail Version 200 3-19-89
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
**********
IMPORTANT: The native mode of the new MBAGGER and MDIST program is
********** the format that will be required by the upcoming GT POWER
15.00 release. In order to use these programs with older
version of GT POWER, you must use the /OC command line
switch with these programs. MDRIVER is compatible with
both formats without need for command line switches.
A change in the way Zmodem file transfers are handled -if an non-zero
return code is received by MDRIVER from the DSZ program, the received
bags, if any, will be moved into a new directory, \MAILIN\PROBLEMS, and
an entry will be made in the GTNET.LOG to document this action. The
sysop should examine these bags, perhaps unpacking them manually or with
a special run of MDIST. But please be prepared for these bags to be
corrupted. In the past, MDRIVER simply erased these bags, but it seems
that DSZ is not returning questionable error signals.
New command line switches for MBAGGER:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/CF ... Suppress all .FR requests encountered during the bagging run.
/CD ... Suppress all .DX requests encountered during the bagging run.
/CA ... Suppress both .FR and .DX requests. As if you had both /CF and
/CD on the command line at the same time.
/Knn .. The 'nn' should be be a unique number between 1 and 65535. It is
used with the .CY command to encrypt messages on your system.
Please note, you should _NOT_ use te same /k number on the MBAGGER
and MDIST command lines. Keep this number SECRET.
/NL ... Suppress the new G bag logging from MBAGGER. If not present,
MBAGGER will cause entries to be written to GBAG.LOG to document
the creation/update of G bags.
/NP ... This option causes the MBAGGER program to skip the pruning of
echomail from \MAILOUT and is quite useful in speeding the
operation of the program. The echomail need not be pruned more
than once a day.
/OC ... This option allows the MBAGGER program to be used with GT POWER 14.03
and before. The native mode of MBAGGER will be the GT POWER 15.00
mode.
/X .... Bag mail in a normal fashion, but skip any echomail conference
which is sponsored by the local sysop. This prevents problems
with multiple baggings on the same day by echomail sponsors.
The echomail sponsor would need at least 1 run per day without
this option.
/Zn ... Use PKZIP to pack bags. The 'n' is the level of compression
desired. Valid values are 1..4. Care should be used to insure
that the system you send bags to can handle ZIP the ZIP format.
Also an explanation of the /Dxx switch. The /Dxx switch will remove
old E bags and maintain the requested number of bags for active conference
areas. For example, /D10 would maintain 10 =days= worth of back E bags.
However, for inactive conferences, i.e. not currently listed in the
MESSAGE DISTRIBUTION section, MBAGGER will leave all E bags to the
disposition of the sysop.
Another change, that is related to the /Dxx switch is a change to the
MESSAGE DISTRIBUTION section. You can now specify an override for any
particular conference. You can maintain more or less than is asked for
by the /D switch with this option in the MESSAGE DISTRIBUTION section.
There are actually two changes to the MESSAGE DISTRIBUTION format, the
second change allows the inclusion of descriptions for the conferences,
which will be included in any .GL report sent to subscribers.
Here is the new format:
MESSAGE DISTRIBUTION
E00/001,5 -> D:\GT_ECHO , GT_Power_Echomail
E00/005,10 -> C:\DOORS , Door_Echomail
E00/009,5 -> C:\SOFTECH , Soft_Tech_Echomail
E00/000,15 -> D:\BETA_ECO , ;Beta_Test_Echo (geewhiz)
E00/019 -> C:\SYSOP , GT_Network_Sysop
E10/009 -> skip , Shareware_Echo
E00/043 -> C:\COOKBOOK , ;Cookbook_Echo
END
In this case, assuming the /D4 setting was in use, MBAGGER would keep
5 days of E00/001, 10 days of E00/005, 5 days of E00/009 and 4 days
worth of E00/019 (/D4 = 4 days). This should give a good deal of
flexibility in dealing with different conditions in different conferences.
Also, note the "_" characters in the description field, these are changed
to blanks by the netmail programs, as need be, since all other blanks are
automatically removed. The description is limited to 20 characters, so
be brief. Also, you may begin a description with a ";" to eliminate a
sensitive conference from the .GL report. (So others need not know I like
to cook! For example. <GRIN>)
Also, please note in the example MESSAGE DISTRIBUTION above, the word
"skip" is given as the pathname for the E10/009 conference. This means
that the conference is not actually maintained on the system. That is,
the sysop keeps the conference in \MAILOUT for others to get, but it is
not bagged or distributed.
Again referring to the MESSAGE DISTRIBUTION above, the line for E00/000
contains the word 'geewhiz' within (...). This indicates that this
conference is garbled using this word. In order to read this conference
you must have the password properly shown in the MESSAGE DISTRIBUTION.
Both sponsor and subscriber use the same password.
New command line switches for MDIST:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Knn .. The 'nn' should be a unique number between 1 and 65535. It is
used with the .CY command to decrypt messages to your system.
Please note, you should _NOT_ use the same /K number on the MDIST
and MBAGGER command lines. Keep the number on your MBAGGER line
secret, _but_ tell those, who wish to send encrypted messages
to you, the number you have selected for use on your MDIST
line (otherwise incoming messages may not be decrypted).
/NA ... No Remote File Attach. This command causes any .RA received
from a remote system to be discarded. A message will be returned
to the sender explaining that the .RA was not authorized.
/NR ... Causes the response to the .GL command to exclude a full list
of available echomail conferences. Instead producing a report
of the current status of the requestor's conferences only.
/NL ... Causes MDIST to suppress keeping the new G bag log. This new
log is now produced by default, and this switch can be used to
suppress it. If the log is kept, a record of each G bag
processed through MDIST and its contents will be kept in a file
called GBAG.LOG. This file will grow indefinitely, it is up to
the sysop to periodically archive it. MDIST will build a new
one if an existing GBAG.LOG file is not found.
/OC ... This option allows the MDIST program to be used with GT POWER 14.03
and before. The native mode of MDIST will be the GT POWER 15.00
mode.
/SB ... Save B bags prior to unpacking and distributing to the message
base. The bags are saved in MAILARC.ARC, which will be created
in the \MAILIN directory. The sysop is responsible for pruning
bags from this archive as required.
/SG ... Save G bags prior to unpacking and distributing. Same as above
for the /SB option.
/SA ... Save both B and G bags prior to unpacking and distributing. Same
as above for the /SB and /SG options.
/V .... This option can be used when G bag logging is enabled (which
is the default). The /V option causes verbose logging of G bags
before they are unpacked. MDIST will invoke PKARC or PKZIP, as
required, with the V option and append the output to the GBAG.LOG
file. Thus providing a complete record of the files contained in
the G bag.
/Zn ... Use PKZIP to pack bags. The 'n' is the level of compression
desired. Valid values are 1..4. This is used to select the
storage method to be used with the /SB, /SG and /SA options
listed above. Unpacking of ZIP format is handled automatically,
the MDIST program will auto-sense ZIP vs ARC format bags.
New command line switches for MDRIVER:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Bnn .. The 'nn' is the number of times you wish to try to connect to a
remote city through PC Pursuit at 2400 baud (if available), before
dropping down to 1200. This parameter only affects the dialing
through PC Pursuit to a remote city (i.e. the Telenet "C D" command).
/Lnn .. This option would cause MDRIVER to try each node only 'nn' times
before removing it from the calling queue for the session. For
example:
/L3
This would cause the MDRIVER to try each node 3
times then giving up. The nodes will be dialed
in the normal rotation, of course --this does not
affect the order in which they are called.
/NC ... This option would cause MDRIVER to take the crash call for long
enough to get the caller's id, then disconnect. Effectively this
is an option to say: NO CRASH CALLS AT THIS TIME. But it will
update the GTNET.LOG file and show you the ID of the calling system.
/NOW .. This can be placed on the command line where the start time is
usually given. This insures that MDRIVER will begin immediately,
no matter what the current time is. Of course, care must still
be taken with the ending time, but the latest start time is now
ignored (although it must still be stated). For example:
New style:
mdriv043 xxxx-yyyy /now 2459 2459 /cc /q /r:routing.cr2 /zc
Old style:
mdriv043 xxxx-yyyy 0100 2459 2459 /cc /q /r:routing.cr2 /zc
/OW ... This option turns the CALL WINDOWS, described below, into a full
scheduling mechanism. All inbounds/outbounds will be auto-generated
to make the MDRIVER call the designated systems at the required
time (all other calls will be automatically suppressed). The
OW stands for "Outbound Windows". Since the /OW option generates
inbound and outbound statements automatically, the node range option
of the CALL WINDOWS should not be used. The program can become
easily confused.
WARNING: DO NOT use the option unless you are using CALL WINDOWS.
Extra outbound calls will be placed if this command is
used in the absence of CALL WINDOWS.
/Q:x .. This is an old option with a new twist. The /Q continues to mean
that the MDRIVER will quit after placing all calls. But now you
may specify a particular node that is to be called. The 'x' has
the format 'net-node'. For example:
/Q:009-000
This would force a call to 009/000, then exit from the
program.
/Q009000
This is the same as above. The punctuation is for
readability only, and may be omitted by the user.
/Q
This would allow MDRIVER to follow the routing
instructions, and quit after all calls have completed.
New dot commands for messages:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.CC ... An internal system command, used by the system to garble netmail
messages. Should not be directly used by individuals.
.CY ... Encrypt the information on the line following. This information
will be returned to normal on the receiving system.
.CS ... Acts like a continuous run of .CY commands. For example if you
wanted to encrypt an entire paragraph or message. Like this:
.CStart
These lines will be encrypted.
This is the second line to be encrypted.
.CStop
The two lines shown between the .CStart and .CStop will be
encrypted. The .CS command works with the .KE command in the
same way that the .CY command does, with the extra attraction
that the .KE command may itself be encrypted. Like this:
.CSstart
.KE 8123
All lines between the .CStart and .CStop are encrypted.
This is another line encrypted.
.CStop
This just adds one more level of protection to sensitive data.
********
WARNING: The encryption feature described herein provides a very low level
******** of protection. It is meant only to keep the curious from reading
your mail. DO NOT rely on it for any substantial purpose. P&M
disclaims the responsibility for any loss incurred due to the use
of this encryption scheme.
.EC ... An internal system command, used by the system to garble echomail
conferences. Should not be directly used by individuals.
.KE ... This command affects the encryption process done by .CY and .CS
so that it is less likely that outsiders will be able to unsramble
the information. The .KE is followed by a number between 1 and
65535, which must match the /K number on the receivers MDIST
command line. For example:
If the receiver told you ahead of time that his code number
was /k8123 on his MDIST command line, then you would code this
in your message:
.KE 8123
.CY
.CY This is an encrypted message, that can be read by
.CY a system with /k8123 on the MDIST command line.
.CY
Then the receiving system should have:
MDIST /r:routing.bbs /k8123
********
WARNING: The change described below to the .FA is dangerous if you have
******** granted the FR permission on a CLASS card in your GTPASSWD.BBS
file to anyone other than the Sysop. Potentially, a caller
could take any file on your system. The best policy would be
to restrict the FR option to only full Sysop level people.
.FA ... The .FA or file attach command is not new, but there has been a
slight change. The .FA command will now accept a path other than
the \MAILOUT\FILEOUT directory.
For example:
.FA foo.bar
Would pick-up FOO.BAR from the \MAILOUT\FILEOUT
directory.
.FA \lotus\spread.wks
Would pick-up SPREAD.WKS from the \LOTUS directory.
********
WARNING: The use of the .Gx commands is probably incompatible with
******** the software provided by other authors. If the sytem you are
sending .Gx commands to is not using compatible software,
these commands will not work properly.
.GL ... If this command is placed in a netmail message to a system
which is sending you a G bag, that system will respond with
a report of the current status of the conferences you are
receiving and, if authorized, a list of conferences available
on that remote system.
Example: .GL
Where the "." is located in the first position of the line.
.GM ... If this command is placed in a netmail message to a system
which is sending you a G bag, it will allow you to add conferences
or modify the day number that you are receiving in a currently
received conference.
Example: .GM e00/001,810
Again, where the "." would be located in the first position of the
line. The GM is followed by a single space and the echo conference
number you wish to add/modify, followed by the new or starting
day number.
.GQ ... If this command is placed in a netmail message to a system
which is sending you a G bag, it will allow you to drop a
conference from the G bag you are receiving.
Example: .GQ e00/001
As above, the "." should be located in the first position of the
line. The GQ is followed by a single space and the echo
conference number you wish to remove.
.MA ... This command is much like the .FA command. It will also accept
full pathname specification or default to the \MAILOUT\FILEOUT
directory, when no pathname is given. It will take the named
file and create a message to be sent with the "cover message".
The attached message will be given the same security level as
the "cover message". One caveat exists, that is the attached
message must be an ASCII text file, the first line of which
has the following: MSG ATTACH. If the message does not contain
the MSG ATTACH header, then the file will not be attached. This
provision is made, so that the sysop will have control over which
ASCII files are attachable in this manner. For example:
.MA c:\wp\text.dat
.RA ... This is a Remote File Attach. The command works much like a
FR (File Request) command, except that it works through normal
network channels, causing the receiving system to generate a
FA for the requested file. Only files located in the
\MAILOUT\FILEOUT directory can be obtained in this manner, as
pathnames are not supported with this command. For example:
.RA foobar.dat
Would generate the following on the host system:
.FA foobar.dat
And automatically send the message and attached file back to the
original requestor.
.RR ... This is the Return Receipt Request. The receiving system will
respond with a message confirming receipt of the message containing
the .RR command. The Return Receipt should be in the following form:
~CS
The following message was received at: 009/000
==============================================
Msg No : 2021
Date : 3-13-89
Time : 20:50
Sender : Paul Meiners
Topic : NOTHING IMPORTANT
Prepared By The MDIST Program: 3-13-89 22:10
~CS
.ORIGIN: 009/000 - the Programmer's Workshop -West!
Note the usage of .CS encryption to help insure accuracy. The
message number is the number of the original message on the
sending system (the one with the .RR command).
.RV ... An internal system command, used by the system to provide 'return
receipts' associated with the .RR command. Should not be directly
used by individuals.
With the advent of the .Gx commands, the treatment of the GCONSOL.CTL
file and the BAG CONSOLIDATION section of the routing file will change.
In the past, the BAG CONSOLIDATION section was in control. Now the
GCONSOL.CTL will control, and it will be maintained by the requestor
via .Gx commands. The BAG CONSOLIDATION section will still have a role
to play however, in that no system will be able to get G bags from the
host system unless an authorizing entry appears in the curren BAG
CONSOLIDATION section (it will act as the trigger). Once triggered tho,
the requesting (or subscribing system) will be able to control the
content of the G bag without the intervention of the host sysop.
A sample .GL report:
An Echomail Status Report For The Sysop Of 009/000:
Conferences available on 001/033: (√) = in G bag!
=================================
√ E00/001,0776 - GT POWER ECHOMAIL
E00/005 - DOOR ECHOMAIL
√ E00/033,0776 - SYSOP TOOLS ECHO
√ E00/043,0774 - COOKBOOK ECHO
Conferences coming to you in G bags from 001/033:
=================================================
E00/001,0776 E00/005,0776 E00/033,0776 E00/043,0774
Prepared By The MDIST Program: 2-15-89 18:04
To further support the use of the ZIP format, a change is being made
to the BAG CONSOLIDATION section. Flags are being added to the node
entries in this section, as follows:
Z ... Use PKZIP to build G bags for the indicated node.
F ... An override for the ';' in the MESSAGE DISTRIBUTION allows
the indicated node to receive a full .GL report when requested.
For example:
BAG CONSOLIDATION
001/032,ZF
E00/001,760
009/000,Z
E00/001,760
E10/000,760
001/003
E00/001
END
Please note that the flags are separated from the node number by a comma.
The order of the flags is optional. And flags are _not_ specified for
individual conferences, but only for regular nodes. In this example, 001/032
would be allowed a complete .GL report, overriding any ';' inhibitors in the
MESSAGE DISTRIBUTION section, and G bags for him would be created with the
PKZIP program. Also in the example, 009/000 would not be given an override
for the .GL report, but would have G bags created with the PKZIP program.
Finally, 001/003 would have no override granted and would get normal ARC
style G bags.
In support of scheduled outbound calls (the system has been rather ad hoc),
a new section of the routing file is being introduced: CALL WINDOWS. The
MDRIVER program will support up to 40 call windows, which will act as a way
to limit the times that particular systems are called. Please note that the
call windows do NOT replace outbound statements, i.e. if you aren't calling
a system, the call window will NOT cause a call to be placed. Here is the
way it should look:
CALL WINDOWS
001/032,1:00-2:00
009/000-999,4:00-4:45
END
Please note that the node range is optional (and should not be used with the
/OW command line switch), but a complete time range must be specified. While
a call window is present in the routing file, the listed systems will only be
called during the designated hours (assuming that a call is triggered by an
outbound statement, the presence of mail or the /Q:x command line option.
It is permissible to have multiple windows per node.
The format of the GTNET.LOG file has changed slightly. The total connect
time is now included on the DISCONNECT entry. Like this:
02-27 18:25 CONNECT 2400 WITH 009/000 CRASH!
02-27 18:25 HOST ID: 009/000. PROG ID: 044
02-27 18:25 RECV MAIL.
02-27 18:26 DISCONNECT 00:00:50
--------
New
Regards,
Paul Meiners
February 27, 1989
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Netmail Version 193 2-4-89
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This version is released very quickly after 192, not to fix a bug, but
to supply a asked for feature (that I had forgotten). Sorry about that!
A new option has been added to the MBAGGER to allow the bagging of
messages which do NOT have the case of the ORIGIN line automatically
forced to uppercase. The /L option on the command line will cause
the MBAGGER to use the NAME= entry from the SCHEDULE.BBS file in the
ORIGIN line of the message without converting it to uppercase.
Regards,
Paul Meiners
February 4, 1989
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Netmail Version 192 2-1-89
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This version (and version 191 before it) is a bug fix release. It
addresses a minor problem in the MDIST program and a problem with
repeated baggings of netmail while G bagging is in use. Hopefully,
these versions are now stable.
Regards,
Paul Meiners
February 1, 1989
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Netmail Version 190 12-8-88
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
o Routing Comment Entries.
To ease the editing of routing files, the netmail suite of
programs will now recognize a comment line in the routing.
Any line that begins with a ";" character (the semi-colon)
will be ignored. This is extremely useful when making
temporary edits to INBOUND and OUTBOUND sections, but may be
of use any place in a routing file.
o Bag Consolidation.
There are several changes brought about by BAG CONSOLIDATION.
The first of which is a new section in the ROUTING.BBS file.
An example follows:
BAG CONSOLIDATION
001/003
E05/000,694
E00/001,695
E00/043,693
001/001
001/008
E00/001,696
E00/043,694
END
The nodes to be consolidated are listed, with the desired echomail
conferences (if any) following. The echomail listing is given followed
by a comma to indicate the highest Julian date that that node has
previously received (before being consolidated). Once an echomail
conference has been consolidated the system will maintain this info
in a file in the \MAILOUT directory called GCONSOL.CTL. At the current
time, any one system may consolidate up to 2,000 echomail conferences
(I hope they have plenty of disk space). Usually, the GCONSOL.CTL
file will be automatically maintained, but from time to time it may
be necessary to clear dead wood, change the value of Julian dates,
provide listings --- these chores will be handled by MEDIT, a companion
program written by Chris Smith, the author of SYSOP TOOLS. Thanks
for the support Chris!
It should be stressed that the listing of echomail conferences in
this manner should only be done at the request of the receiving system
and effects the flow of E bags to downstream nodes, i.e. you do _not_
consolidate E bags to be sent back up the echo-chain. YOU DO NOT DO
THAT.
To assist this new operation, each of the netmail programs has added
the /G command line switch. It means something slightly different
for each processor. As follows:
MBAGGER /G /R:foox.bar
This command would not bag mail! Instead it would only
analyze existing mailbags to see if any consolidations
can be performed.
MDIST /G /R:fooy.bar
This command would not distribute mail to the GT POWER
message areas! Instead it will examine all consolidated
bags that have been received addressed to the local node
and break them down into their component parts.
MDRIVER xxxx-yyyy ... /G ...
This command would cause the MDRIVER program to SHELL
to a special batch file at the end of any call during
which the local system has received a consolidated bag.
The name of the special batch file is G_UNPAK.BAT. A
sample follows:
MDIST /R:r0100.bbs /G
MBAGGER /R:routing.cr1 /G
This would cause any consolidated bag received during
a session to be immediately broken down and re-consolidated
in the indicated manner (by the routing and bag consolid-
ation instructions).
A word about how bag consolidation works.
First the routing instructions are examined to see if mail bags are
being routed through a common system and consolidation has been
requested for that common system. These bags are then placed into
a consolidation bag, without having been unpacked (bags within bags).
Then the BAG CONSOLIDATION instructions are examined to see if any
echomail conferences are to be included (they need not be included).
If echomail conferences are included, care is taken to insure that
old 'E' bags are not included - information for this purpose is
recorded in the GCONSOL.CTL file (so don't erase it). Once all
consolidations are performed, the resulting consolidated bags may
be consolidated into themselves (if a common routing is discovered
for consolidated bags).
Please note that the B bags in echo conferences are consolidated
based on the indicated routing, NOT on the listing of echo
conferences in the BAG CONSOLIDATION section. In plain English,
the B bags for an echo conference are treated like ordinary netmail
and the BAG CONSOLIDATION listing of echo conferences only effects
the handling of E bags (those that [E]cho from a sponsor's system).
For example:
ACCEPT 001/008 -> 001/003
ACCEPT 001/001 -> 001/003
ACCEPT E00/001 -> 001/003
BAG CONSOLIDATION
001/003
E00/049
E00/043
001/008
E00/001
E00/043
END
Assuming mail is present for 001/001, 001/003, and 001/008, two
consolidated bags would be created, one for 001/003 and one for
001/008, then since 001/008 is routed through 001/003, the
consolidated bag for 001/008 will be put inside the bag for 001/003.
The final result will be 1 bag for 001/003. When 001/003 receives
this bag, that system will discover the consolidated bag for 001/008
and will forward it as directed by its own routing instructions.
Consolidated bags are very much the same in appearance as ordinary
B bags. Except that they are named with G as the first letter. And
there will be G1 and G2 bags created, in the same manner as the B1 and
B2 bags. These backup bags should be removed on a routine basis, to
prevent un-needed clutter.
o There are two new command line options for use with MDRIVER.
As follows:
/NL ....... Do not answer incoming calls. Assumes sysop is present
and will not continue normal operation after a RING is
detected, until sysop hits the <CR> key.
/NR ....... Do not answer incoming calls. Assumes sysop is _not_
present and _will_ continue normal operation after a
30 second pause. No keystroke is required to restart
operation.
These options are useful if you wish to make a outgoing crash mail
call from a phone normally used for voice operations. Please note
that these options should _not_ be used on your regular data line,
since they will interfere with the normal handling of incoming calls.
o 2400 baud support for PC Pursuit:
MDRIV039 is the first version of the mail driver to support 2400
baud on the PC Pursuit service. The first thing that everyone must
understand is that not all cities have 2400 baud outbound access and
not all cities have 2400 baud inbound access. So, we must be able
to mix and match these items. There must be a way to control the
different access numbers and the different city characteristics.
Please note the new format:
PURSUIT
ACCESS/12=227-1018
ACCESS/24=227-8208
USERID=xxxxxxxx
PASSWORD=yyyyyyyy
CITIES
201,NJNEW/12-Newark
216,OHCLE/12-Cleveland
202,DCWAS/24-Washington
305,FLMIA/12-Miami
206,WASEA/12-Seattle
408,CASJO/12-San_Jose
212,NYNYO/24-New_York
718,NYNYO/24+New_York
414,WIMIL/12-Milwaukee
213,CALAN/12-Los_Angeles
503,ORPOR/12-Portland
214,TXDAL/24-Dallas
END
First, the syntax of the ACCESS entry has changed. The word ACCESS
is now followed by either "/12" or "/24", to identify that number
as to the indicated baud rate supported.
Then in the table of cities, please note that each city code is also
followed by a "/12" or "/24" to indicate if the city has 2400 inbound
capabilities. Each city must have this annotation added, as
appropriate.
o New log entries.
To help with debugging Telenet problems a new entry in the GTNET.LOG
file will identify the Telenet terminal you are connected to. For
example, the following would appear in your log:
CONNECTED VIA PCP TO CLEVELAND 713 18Q
Where "713 18Q" is the id for the Telenet terminal you are locally
connected to.
Also, for the sake of easier debugging by the programmer, the log
will now show the version number of the MDRIVER in use. This will
be displayed on the START OF SESSION line like this:
START OF NETMAIL SESSION - 039
Regards,
Paul Meiners
December 8, 1988
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Netmail Version 180 11-4-88
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This version of the netmail software is introduces a new Echomail
CRC mechanism for sponsors of Echomail Conferences. If you are the
sponsor of an Echomail Conference YOU MUST GET NEW CRC's for your
conference. The new CRC mechanism will insure that only the authorized
net/node will be able to sponsor the indicated Echomail Conference.
This change should not effect anyone, except for the sponsors of Echomail
Conferences.
This release also includes some minor bug fixes in the area of the Fixed
DTE handling and the Destination Reporting.
Regards,
Paul Meiners
November 4, 1988
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Netmail Version 150 10-18-88
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
o New command line paramters, MDRIVER:
/Mn ..... Limits outgoing calls so that they will not "fallback"
below this lower limit. The 'n' is the lowest baud rate
that may be used in a "fallback" situation.
For example:
/M2400
would limit "fallbacks" so that they would not go below
2400 baud.
/ZC ..... Enables the use of the Zmodem protocol through DSZ.COM.
/ZE ..... Enables the use of the Zmodem protocol through DSZ.EXE.
If you are enabling either DSZ, then the version selected, either
EXE or COM, must be available in the GT POWER home directory. For
example, if you have:
set GTPATH=C:\GT
Then DSZ must be located in the C:\GT directory. It is not invoked
via a "shell" or a batch file, but for the sake of security and speed,
it is executed directly from MDRIVER as a "child" process. This
allows a very close coorperation between the two programs. But the
result is that the normal ZM??.BAT batch files cannot be used, nor is
the regular DOS PATH searched to find DSZ.
o CRASH! Mail Feature:
A new feature. CRASH! Mail allows the netmail software to run
in a nearly ad hoc fashion. Picking up and delivering E-Mail
at virtually any time.
To enable CRASH! Mail, the nodelist must be updated to reflect
which systems are "crashable". This is done by placing an '*'
before the system name. For example:
001/001 713-772-2090 24 Houston PROGRAMMERS WORKSHOP Paul Meiners
001/002 713-664-7679 24 Houston PRIVATE SECTOR ...... Chris Smith
001/003 713-778-9471 96 Houston *P&M TEST SYSTEM ..... Paul Meiners
001/007 713-799-5545 24 Houston JOSHUA TREE ......... Larry Rushing
Under CRASH! Mail, the GT POWER Host Mode will identify incoming
netmail calls and pass control to the GTCRASH.BAT file, which the
SYSOP must prepare to accept CRASH! Mail calls, using instructions
provided in the Netmail Beta Documentation. Under the CRASH! Mail
concept, incoming netmail can be handled on an ad hoc basis. But
outgoing calls must continue to be scheduled. Outgoing CRASH! Mail
calls may be scheduled at virtually any time (assuming that the
destination is capable of Crash Mail).
The DOOR.EXE program must be available, as described above, for
GTCRASH.BAT to be properly invoked.
PLEASE NOTE:
The DOOR.EXE program is part of the upcoming GT POWER 14.03 release.
With this netmail code, you will be able to make outgoing CRASH!
Mail calls, to systems that are running the beta test version of
14.03. No system will be able to accept CRASH! Mail unless they are
using release 14.03 or later of GT POWER.
o New command line options for MDRIVER to handle CRASH! Mail:
/CC ..... Make outgoing CRASH! Mail calls.
/CA%3 ... Answer incoming CRASH! Mail call. This should only be
used in the GTCRASH.BAT file, which is automatically
invoked by the GT POWER host when an incoming CRASH! Mail
call is received. This option will only be usable when
GT POWER 14.03 is released.
The "Crash Answer" command line switch must be followed
by "%3", so that the GT POWER Host can pass the baud rate
to the MDRIVER program. This option should only be used
within the GTCRASH.BAT batch file.
After an incoming CRASH! Mail call is finished, MDRIVER
will automatically release control and allow the reloading
of the GT POWER Host.
An example of a GTCRASH.BAT file is shown below:
c:
cd \gt
mdriv033 9999-9999 /CA%3 /ZE
mdist
o Other changes in netmail software:
This beginnings of support for "Fixed DTE" are being introduced to
MDRIVER. This accords greater support for high speed modems, such
as the USR Courier HST and others.
The netmail programs are being expanded so that a system may have
up to 100 echomail conferences listed in the MESSAGE DISTRIBUTION
section, up from 50 conferences in the previous release.
Chuck Forsberg has been approached about the use of DSZ with the
netmail programs. He has agreed to let this take place, however both
Chuck and I encourage you to register DSZ if you are going to use it.
It is the right thing to do, so send the man some money. He deserves
it for the great product and the great support he gives to it.
Regards,
Paul Meiners
October 18, 1988